home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / security / doc / clippings / 910821-01 < prev    next >
Encoding:
Internet Message Format  |  1991-09-11  |  4.2 KB
  1. From: jkp@cs.HUT.FI (Jyrki Kuoppala)
  2. Newsgroups: alt.security,alt.sys.sun,comp.unix.admin
  3. Subject: A security problem in SunOS 4.1.1 and earlier with in.comsat and /etc/utmp
  4. Message-ID: <1991Aug21.152339.11436@nntp.hut.fi>
  5. Date: 21 Aug 91 15:23:39 GMT
  6. Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
  7. Organization: Helsinki University of Technology, Finland
  8.  
  9. [ followups to alt.security ]
  10.  
  11. I hope that somebody with SunOS source can make a fixed version of
  12. in.comsat available for the net.  Still, the suggested fixes #2 and #3
  13. are a good idea to do anyway.  They apply for generic BSD-based
  14. systems as well.
  15.  
  16. This bug has been reported to Sun and CERT in March of 1991 by me.  It
  17. has also been reported to Sun and CERT in May of 1990 by NASA.
  18.  
  19. More information can be found in manual pages in.comsat(8), inetd(8),
  20. inetd.conf(5) and utmp(5).
  21.  
  22.  
  23. The rest of this article is quoted from the bug report I sent.
  24.  
  25. >From jkp Fri Mar 22 21:10:44 1991
  26. From: Jyrki Kuoppala <jkp@cs.hut.fi>
  27. Subject: Serious trouble with SunOS comsat / world-writable utmp
  28. Return-Receipt-To: <jkp@cs.hut.fi>
  29. Organization: Helsinki University of Technology, Finland.
  30.  
  31. > Newsgroups: alt.security
  32. > From: jkp@cs.HUT.FI (Jyrki Kuoppala)
  33. > Subject: A much more serious problem w/ world-writable utmp & comsat
  34. > Message-ID: <1991Mar22.184621.5049@santra.uucp>
  35. > Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
  36. > Organization: Helsinki University of Technology, Finland
  37. > References: <1991Mar20.011741.13849@santra.uucp> <1991Mar20.185915.27296@santra.uucp> <7378@idunno.Princeton.EDU> <1991Mar22.162102.3302@santra.uucp>
  38. > Date: Fri, 22 Mar 91 18:46:21 GMT
  39. > Lines: 18
  40. > 
  41. > Seems like comsat with world-writable utmp and/or /usr/spool/mail
  42. > opens up a real can of worms.  It appears to be possible to overwrite
  43. > any executable-to-owner file.  It appears to be possible to gain root
  44. > access with only an ordinary account on the machine - and if you run a
  45. > non-restricted tftp daemon, on some situations also even with no
  46. > account on the machine.
  47. > 
  48. > Suggested fix(es):
  49. > 
  50. > 1. Don't run comsat for now until all of this is sorted out and proper fixes
  51. >    are available.
  52. >    This perhaps makes the situation somewhat better even if you don't change
  53. >    utmp and /usr/spool/mail protections.  But it won't fix all of the
  54. >    security problems.
  55. > 2. Don't keep /etc/utmp writable to the world.
  56. > 3. Don't keep /usr/spool/mail writable to the world.
  57. > 
  58. > //Jyrki
  59.  
  60. Works like this:
  61.  
  62. - make a symlink /tmp/x pointing to the executable file you want to overwrite.
  63.   If you want to gain root access make this a file that root will execute.
  64. - mail a message to root with a shell script you want to write over
  65.   the executable with (if root mail is not redirected).  If root mail
  66.   is redirected, probably there is no /usr/spool/mail/root and you can
  67.   just create your own.  Might be also possible to use \root to write
  68.   to /usr/spool/mail/root even if it is forwarded.  If /usr/spool/mail
  69.   is write protected and root mail is forwarded to someone else,
  70.   it might not be that easy - but anyway, if that's the case then
  71.   anyone else's files (for those whose mail is not forwarded) can be
  72.   overwritten.
  73. - edit /etc/utmp to have an entry for user `root' with tty line
  74.   `../tmp/x'
  75. - send a message `root@offset' with the right offset to comsat.  It
  76.   will overwrite the file /tmp/x points to - while adding some garbage
  77.   like `New mail for root has arrived'.
  78. - when root runs the overwritten command, shell will complain somewhat
  79.   about the garbage lines but the lines from the mail which are proper shell
  80.   commands (with for example ; at the end of line to make the ^M not
  81.   cause trouble) will be executed.
  82.  
  83. Tested on SunOS 4.1 and 4.1.1.  Might not directly concern systems
  84. where utmp and /usr/spool/mail are not world-writable, but it'd be a
  85. good idea to make comsat do some additional checking anyway.  Also, on
  86. many systems with writable /usr/spool/mail it's possible to read
  87. other's mail by mv'ing their mail files to yourself and then sending
  88. some mail to yourself (if I remember right).  This could be used to
  89. read other files also, if on the same file system as /usr/spool/mail.
  90. So the advice to chmod o-w /usr/spool/mail still holds.
  91.  
  92. People at Sun, please ack this message.
  93.  
  94. //Jyrki
  95.  
  96.